Is there any best-practices documentation about doing this kind of thing? It seems better to follow some existing process rather than to invent one for ourselves here.

It's a GitHub Action maintained by the Rust Secure Code Working Group, see https://rustsec.org.

Rustix is a library. Libraries don't need to do anything for patch-level and minor-level dependency updates. Major-level and switch-depemdencies updates are less common, and we'll get bug reports from users when they do happen. It would be slightly nicer if we didn't need to wait for those bug reports, but it's not clear that the maintainer burden is worth it.

If there's a best practices doc that accounts for practical costs and practical benefits, I'm open to reading it.

https://anssi-fr.github.io/rust-guide/libraries.html

That link doesn't address my concerns.

I am concerned that a daily audit will produce many notifications that don't require any action within rustix.

I also assume that Rust library security updates that require major-version bumps or switching libraries are uncommon, and when they do happen, it's uncommon for them to be urgent.

Consequently, I don't think it's worthwhile for rustix to run a daily audit.

The changes in this PR would adjust the workflow so that advisories are surfaced but do not cause CI to fail, providing visibility into potential issues.

As well as vulnerabilities, the action also reports unsoundness advisories. In the case of unsoundness, fixes are often not backported.

For example, cargo audit currently reports:

Crate:     atty
Version:   0.2.14
Warning:   unsound
Title:     Potential unaligned read
Date:      2021-07-04
ID:        RUSTSEC-2021-0145
URL:       https://rustsec.org/advisories/RUSTSEC-2021-0145
Dependency tree:
atty 0.2.14
└── criterion 0.4.0
    └── rustix 1.1.3

This was fixed in criterion 0.5.0, but the fix was not backported to the 0.4.x series. Unfortunately, criterion 0.5.0 requires an MSRV of 1.64.

With Rust 1.63 dating back to August 2022, this is increasingly problematic: many crates have since raised their MSRV, and fixes, especially for unsoundness, often land only in new major versions.

criterion is a dev-dependency in rustix. It's only used for cargo bench. I'm surprised that cargo audit reports things from dev-dependencies as vulnerabilities. This would be another reason why it's a burden for maintainers.

If the script is set to produce no notifications, then I don't understand why it's important to do. If downstream users want to know about potential issues in their dependencies, they'll run cargo audit in their own CI anyway.

Also, yes, we probably should bump the MSRV to something newer now.